Organizations rely more and more on computer-based systems to store and access information. Information is stored in data stores. A key issue to store and access information in data stores is the consistency guaranteed by the data store. One of the most common ways to provide consistency is by means of transactional data management typically provided by databases and multi-tier systems, and more recently by other modern data stores.
A transaction is a process that enables concurrent access to shared data and guarantee implicitly (without any direct coordination among client applications) the so-called ACID properties, atomicity, consistency, isolation and durability. Atomicity guarantees that the effect of a transaction is all or nothing, that is, that either all its writes take effect or none of them, even in the advent of failures. Consistency is a property guaranteed by the correctness of the client applications, if a transaction is executed over a database in a consistent state with respect the application semantics the result after executing and committing the transaction should again be consistent, that is, the client applications should be correct. Isolation is a property that regulates how concurrent transactions are managed so they observe and write data with a given set of guarantees. Durability is a property that states that once a transaction has committed successfully its writes cannot be lost even in the advent of failures.
Isolation of transactions is guaranteed by means of concurrency control. One common concurrency control mechanism is called snapshot isolation. Snapshot isolation splits atomicity in two points: reads happen logically at the start of the transaction and writes happen logically at the end of the transaction. This is a slightly more relaxed isolation level than serializability in which the atomicity of a transaction happens at a single point, that is, the transaction read and writes happen at a single logical point. Snapshot isolation only disallows concurrent writes, whilst serializability additionally disallows concurrent reads and writes on the same data items.
A key problem in transactional data management is how to scale out the processing. That is, how to use an increasing number of computational resources to process a higher rate of transactions.
A transaction upon start is assigned a snapshot of the database, that is, the set of committed writes that it will observe. Snapshot isolation is a multi-versioning isolation method. For each data item multiple versions are kept that are tagged with order labels. These labels are also referred as timestamps in the state of art. When a read only transaction (transactions that have not performed any write) commit, no special action is taken. When an update transaction (a transaction that has performed at least one write) is committed, it is assigned an order in the sequence of committed transactions. That is, for any two committed update transactions the order in the sequence determines which one committed before the other. Snapshot isolation is currently guaranteed by committing update transactions sequentially and giving new started transactions a snapshot corresponding to the current sequence of committed update transactions.
Additionally, concurrent transactions are not allowed to update common data items. Conflicts are either resolve when they happen by aborting one of the conflicting transactions or at commitment time by aborting a committing transaction that is concurrent to a conflicting transaction that has committed before it.
The kind of transactional processing creates contention due to several reasons. The main reason is that commit processing and the synchronization between the start of new transactions and the commit of completing become a bottleneck.
In the present invention, this bottleneck is removed and its ultimate bottleneck still enables to execute very high rates of update transactions preserving full transactional consistency.